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DETAILED ACTION 

1 . This office action replaces the prior first ( non final) office action, mailed 1 1/23/2004. 

2. Claims 1-68 are pending for examination. 

3. Claims 1-68 are rejected. 

Claim Rejections - 35 USC § 112 
The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

The term "match" in claims 42,43,50,51,55,56,59,60,65,68 is a relative term which 
renders the claim indefinite. The term "match" is not defined by the claim, the specification does 
not provide a standard for ascertaining the requisite degree or context of said "match" 
determining or testing for, and one of ordinary skill in the art would not be reasonably apprised 
of the scope of the invention. Correction is required.. 

Oaim Rejections - 35 USC §102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

4. Claims 1-68 are rejected under 35 U.S.C. 102(b) as being anticipated by Schneier et al, 
U.S. Patent 6,099,408. 
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5. As per claim 1 ; "A computer-based method for a multiparty electronic service [i.e., 
Abstract, whereas the playing of electronic games over a network by one or more players 
corresponds to the 'multiparty electronic service'], the method comprising steps of negotiating a 
machine interpretable service specification between all parties, which would cooperate with a 
particular application running on a host system [i.e., col. 1, lines 55-col. 17,line 28, whereas the 
setup of wagers, game selection, players selection/authentication, payment authorization, etc., on 
a per player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), 
particularly, clearly teaches of 'service specification between all parties' as to the setup prior to 
playing online games/establishing associated random number information associated with said 
playing of games.]; defining said service specification to: identify cooperating parties [i.e., col. 1, 
lines 55-col. 17,line 28, whereas the setup of players selection/authentication, on a per player per 
se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly 
teaches of 'identify cooperating parties'. Also, multiple players/game would clearly have to be 
identified such that the server database referencing is a function of the client identity as an index 
into the said database.]; identify a requestor and format of a service request, said request is 
adapted to contain information about an individual [i.e., col. 1, lines 55-col. 17,line 28, whereas 
the setup of players selection/authentication, on a per player per se, and multiple player 
embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 'requestor and 
format of a service request' insofar as the communications protocols of the game initiator at least 
is concerned (i.e., figure 4 and associated description).]; conduct conditional processing steps 
required for said service request, said conditional processing steps is adapted to use stored data 
about said individual [i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of players 
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selection/authentication, on a per player per se, and multiple player embodiments (col. 12,lines 
35-col 17,line 27), particularly, clearly teaches of 'conditional processing steps is adapted to use 
stored data about said individual 5 .]; and provide conditional notifications, said notifications is 
adapted to include additional information about the individual described in the request [i.e., col. 
1, lines 55-col. 17,line 28, whereas the setup of players selection/authentication, on a per player 
per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly 
teaches of 'additional information about the individual described in the request' insofar as the 
requestor clearly must have submitted user information in the game registration process as any of 

s 

the other player are similarly required to do so.]; providing a secure computation environment in 
said host system [i.e., col. 1, lines 55-col. 17,line 28, whereas the cryptographic processors, on a 
per player user client terminal and server side host, clearly teaches of 'secure computation 
environment 5 .]; uploading said service specification into said secure computation environment 
[i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of players selection/authentication, on a 
per player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches of 'uploading said service specification' insofar as the clients and servers clearly 
have the same rules and all associated information required to play.]; enforcing said service 
specification with regards to all cooperating parties [i.e., col. 1, lines 55-col. 17,line 28, whereas 
the setup of players selection/authentication, on a per player per se, and multiple player 
embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 'enforcing said 
service specification with regards to all cooperating parties' insofar as the clients and servers 
clearly have the same rules and all associated information required to play, and as such use said 
information during the actual game playing.]; receiving a service request from said requestor 
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[i.e., col. 1, lines 55-col. 17,line 28, whereas the subsequent to the setup of players 
selection/authentication, on a per player per se, and multiple player embodiments (col. 12,lines 
35-col 17,line 27), particularly, clearly teaches of 'receiving a service request from said 
requestor' insofar as the clients and servers clearly have the same rules and all associated 
information required to play, and as such use said information during the actual game playing.]; 
providing a secure co-processor in said secure computation environment for processing said 
service request, where said secure processing includes: determining the service specification that 
governs said service request; validating the actual requestor and the content of the service request 
against an expected requestor and expected contents as defined in the service specification; and 
executing the conditional processing and the notifications as defined in the service specification 
[i.e., col. 1, lines 55-col. 17,line 28, whereas the cryptographic processors, on a per player user 
client terminal and server side host, clearly teaches of 'secure computation environment' insofar 
as the authentication and actual game playing cryptographic functions serviced via the 
cryptographic processor secure computing environment.]."; 

Further, as per claim 17; "Apparatus [This claim is the system claim for the method claim 
1 above, and is rejected for the same reasons provided for the claim 1 rejection] for a multiparty 
electronic service, the apparatus comprising: at least one host computer adapted to have at least 
one secure co-processor operating in a secure computation environment, said at least one host 
computer operative to: negotiate a machine interpretable service specification between all 
parties, which would cooperate with a particular application running on said host computer; 
upload said service specification into said secure computation environment; enforce said service 
specification with regards to all cooperating parties; receive a service request from a requestor; 
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execute secure processing of said service request; and provide notifications as defined in the 
service specification."; 

Further, as per claim 35; "A program storage device readable by a machine, tangibly 
embodying a program of instructions executable by the machine to perform methods steps [This 
claim is the embodied software claim for the method claim 17 above, and is rejected for the same 
reasons provided for the claim 17 rejection] for managing a matching identification service, the 
method comprising the steps of: negotiating a machine interpretable service specification 
between all parties, which would cooperate with a particular application running on a host 
system; defining said service specification to: identify cooperating parties; identify a requestor 
and format of a service request, said request is adapted to contain information about an 
individual; conduct conditional processing steps required for said service request, said 
conditional processing steps is adapted to use stored data about said individual; and provide 
conditional notifications, said notifications is adapted to include additional information about the 
individual described in the request; providing a secure computation environment in said host 
system; uploading said service specification into said secure computation environment; enforcing 
said service specification with regards to all cooperating parties; receiving a service request from 
said requestor; providing a secure co-processor in said secure computation environment for 
processing said service request, where said secure processing includes: determining the service 
specification that governs said service request; validating the actual requestor and the content of 
the service request against an expected requestor and expected contents as defined in the service 
specification; and executing the conditional processing and the notifications as defined in the 
service specification.". 
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Further, as per claim 34; "An article of manufacture [This claim is the embodied software 
claim for the method claim 1 above, and is rejected for the same reasons provided for the claim 1 
rejection] for use in a multiparty electronic service, comprising a machine readable medium 
tangibly embodying a program of instructions executable by a machine for implementing a 
method, the method comprising steps of: negotiating a machine interpretable service 
specification between all parties, which would cooperate with a particular application running on 
a host system; defining said service specification to: identify cooperating parties; identify a 
requestor and format of a service request, said request is adapted to contain information about an 
individual; conduct conditional processing steps required for said service request, said 
conditional processing steps is adapted to use stored data about said individual; and provide 
conditional notifications, said notifications is adapted to include additional information about the 
individual described in the request; providing a secure computation environment in said host 
system; uploading said service specification into said secure computation environment; enforcing 
said service specification with regards to all cooperating parties-,receiving a service request from 
said requestor; providing a secure co-processor in said secure computation environment for 
processing said service request, where said secure processing includes: determining the service 
specification that governs said service request; validating the actual requestor and the content of 
the service request against an expected requestor and expected contents as defined in the service 
specification; and executing the conditional processing and the notifications as defined in the 
service specification.". 
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6. Claim 2 additionally recites the limitation that; "The method of claim 1 further 
comprising the step of allowing at least one party of said cooperating parties to cancel said 
service specification wherein all future service requests that rely on said cancelled service 
specification will be rejected". The teachings of Schneier et al are directed towards such 
limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game selection, 
players selection/authentication, payment authorization, etc., on a per player per se, and multiple 
player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches, insofar as if 
any player decides he doesn't want to continue, that criteria, at the least, is inherent in the 
number of wagers type of specification for playing a given game round setup, as broadly 
interpreted by the examiner would clearly encompass 'one party of said cooperating parties to 
cancel said service specification wherein all future service requests that rely on said cancelled 
service specification will be rejected'.). 



7. Claim 3 additionally recites the limitation that; "The method of claim 2 wherein said 
steps of negotiating a machine interpretable service specification, uploading, enforcing, receiving 
a service request, and canceling said service specification comprises the step of conducting said 
previous steps multiple times.". The teachings of Schneier et al are directed towards such 
limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game selection, 
players selection/authentication, payment authorization, etc., on a per player per se, and multiple 
player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches, insofar as if 
any player decides he doesn't want to continue, that criteria, at the least, is inherent in the 
number of wagers type of specification for playing a given game round setup, as broadly 
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interpreted by the examiner would clearly encompass 'previous steps multiple times' such that 
multiple rounds of play are clearly playable.); 

Further, as per claim 22 additionally reciting the limitation that; "The apparatus of claim 
17 wherein said at least one host computer operative to negotiate said machine interpretable 
service specification, upload said service specification, enforce said service specification, and 
receive a service request, is further operative to conduct said negotiating, uploading, enforcing 
and receiving functions multiple times.". The teachings of Schneier et al are directed towards 
such limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game 
selection, players selection/aiuthentication, payment authorization, etc., on a per player per se, 
and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches, 
insofar as if any player decides he doesn't want to continue, that criteria, at the least, is inherent 
in the number of wagers type of specification for playing a given game round setup, as broadly 
interpreted by the examiner would clearly encompass 'previous steps multiple times' such that 
multiple rounds of play are clearly playable.). 

8. Claim 4 additionally recites the limitation that; "The method of claim 1 further 
comprising the steps of: negotiating multiple machine interpretable service specifications; 
defining said multiple service specifications; uploading said multiple service specifications into 
said secure computation environment; and enforcing said multiple service specifications with 
regards to all cooperating parties ". The teachings of Schneier et al are directed towards such 
limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game selection, 
players selection/authentication, payment authorization, etc., on a per player per se, and multiple 
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player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches, insofar as if 
any player decides he wants to continue playing, that criteria, at the least, is inherent in the 
number of wagers type of specification for playing a given game in a multi round setup, as 
broadly interpreted by the examiner would clearly encompass 'multiple service specifications 
with regards to all cooperating parties'.); 

Further, as per claim 28 additionally reciting the limitation that; "The apparatus of claim 
17 wherein said at least one host computer operative to negotiate a machine interpretable service 
specification between all parties is further operative to: negotiate multiple machine interpretable 
service specifications; define said multiple service specifications; upload said multiple service 
specifications into said secure computation environment; and enforce said multiple service 
specifications with regards to all cooperating parties The teachings of Schneier et al are 
directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of 
wagers, game selection, players selection/authentication, payment authorization, etc., on a per 
player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches, insofar as if any player decides he wants to continue playing, that criteria, at the 
least, is inherent in the number of wagers type of specification for playing a given game in a 
multi round setup, as broadly interpreted by the examiner would clearly encompass 'multiple 
service specifications with regards to all cooperating parties 5 .). 

9. Claim 5 additionally recites the limitation that; "The method of claim 4 wherein said 
secure processing steps further comprises the step of having at least one of said secure 
processing steps being executed unconditionally.". The teachings of Schneier et al are directed 
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towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game 
selection, players selection/authentication, payment authorization, etc., on a per player per se, 
and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches, 
insofar as if any player decides he wants to play per se, that criteria, at the least, is inherent in the 
fact that the secure processing via the cryptographic processor(s) used in the authentication or for 
as game appropriate, random number generation services, as broadly interpreted by the examiner 
would clearly encompass 'secure processing steps being executed unconditionally'.). 

10. Claim 6 additionally recites the limitation that; "The method of claim 1 wherein said 
secure processing steps further comprises the step of having at least one of said secure 
processing steps use data provided in said service request and found in said host system to derive 
further information about said individual described in said service request.". The teachings of 
Schneier et al are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas 
the setup of wagers, game selection, players selection/authentication, payment authorization, etc., 
on a per player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), 
particularly, clearly teaches, insofar as if any player decides he wants to play per se, that criteria, 
at the least, is inherent in the fact that the secure processing via the cryptographic processor(s) 
used in the authentication or for as game appropriate, random number generation services, as 
broadly interpreted by the examiner would clearly encompass c at least one of said secure 
processing steps use data provided in said service request and found in said host system to derive 
further information about said individual described in said service request' insofar as the user 
information at the client and server databases associated with the game communicate 



Application/Control Number: 10/065,802 Page 12 

Art Unit: 2136 

intermediate results/messages (i.e., handshaking, authentication results/requests for further 
information, etc.) as part of the setup/authorization/authentication process.); 

Further, as per claim 23 additionally reciting the limitation that; "The apparatus of claim 
17 wherein said at least one host computer is further operative to use data provided in said 
service request and found in said host computer to derive further information about an individual 
described in said service request.". The teachings of Schneier et al are directed towards such 
limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game selection, 
players selection/authentication, payment authorization, etc., on a per player per se, and multiple 
player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches, insofar as if 
any player decides he wants to play per se, that criteria, at the least, is inherent in the fact that the 
secure processing via the cryptographic processor(s) used in the authentication or for as game 
appropriate, random number generation services, as broadly interpreted by the examiner would 
clearly encompass 'at least one of said secure processing steps use data provided in said service 
request and found in said host system to derive further information about said individual 
described in said service request' insofar as the user information at the client and server 
databases associated with the game communicate intermediate results/messages (i.e., 
handshaking, authentication results/requests for further information, etc.) as part of the 
setup/authorization/authentication process.). 

1 1 . Claim 7 additionally recites the limitation that; "The method of claim 6 wherein said at 
least one of said secure processing steps further comprises the step of computing a correlation 
between biometric data provided in said service request and biometric data looked up in said host 
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system ". The teachings of Schneier et al are directed towards such limitations (i.e., col. 6, lines 
39-65, col. 15,lines 66-col. 16,line 64, whereas the players selection/authentication on a per 
player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches of the appropriate use of biometrics, as broadly interpreted by the examiner, and 
would thus clearly encompass 'correlation between biometric data provided in said service 
request and biometric data looked up in said host system'.); 

Further, as per claim 24 additionally reciting the limitation that; "The apparatus of claim 
23 wherein said at least one host computer is further operative to compute a correlation between 
biometric data provided in said service request and biometric data looked up in said host 
computer The teachings of Schneier et al are directed towards such limitations (i.e., col. 6, 
lines 39-65, col. 15,lines 66-col. 16,line 64, whereas the players selection/authentication on a per 
player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches of the appropriate use of biometrics, as broadly interpreted by the examiner, and 
would thus clearly encompass 'correlation between biometric data provided in said service 
request and biometric data looked up in said host system'.); 

Further, as per claim 25 additionally reciting the limitation that; "The apparatus of claim 
17 wherein said at least one host computer is further operative to compute a correlation between 
biometric data provided in said service request and biometric data looked up in said host 
computer The teachings of Schneier et al are directed towards such limitations (i.e., col. 6, lines 
39-65, col. 15,lines 66-col. 16,line 64, whereas the players selection/authentication on a per 
player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches of the appropriate use of biometrics, as broadly interpreted by the examiner, and 
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would thus clearly encompass 'correlation between biometric data provided in said service 
request and biometric data looked up in said host system'.). 



12. Claim 8 additionally recites the limitation that; "The method of claim 1 wherein said step 
of providing conditional notifications further comprises the step of providing an empty 
message.". The teachings of Schneier et al are directed towards such limitations (i.e., col. 5,lines 
38-col. 6,line 38, whereas the players selection/authentication on a per player per se, and 
multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of the 
messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
'providing conditional notifications further comprises the step of providing an empty message' 
insofar as the user information at the client and server databases associated with the game 
communicate intermediate results/messages (i.e., handshaking, authentication results/requests for 
further information, etc.) as part of the setup/authorization/authentication process, and said 
messages clearly (i.e., again, in the case of handshaking, authentication results/requests for 
further information, etc.) encompass said empty messages.); 

Further, as per claim 26 additionally reciting the limitation that; "The apparatus of claim 
17 wherein said at least one host computer operative to provide notifications is further operative 
to provide an empty message". The teachings of Schneier et al are directed towards such 
limitations (i.e., col. 5,lines 38-col. 6,line 38, whereas the players selection/authentication on a 
per player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches of the messaging protocols, as broadly interpreted by the examiner and would 
clearly encompass 'providing conditional notifications further comprises the step of providing an 




Application/Control Number: 10/065,802 Page 15 

Art Unit: 2136 

empty message' insofar as the user information at the client and server databases associated with 
the game communicate intermediate results/messages (i.e., handshaking, authentication 
results/requests for further information, etc.) as part of the setup/authorization/authentication 
process, and said messages clearly (i.e., again, in the case of handshaking, authentication 
results/requests for further information, etc.) encompass said empty messages.). 

13. Claim 9 additionally recites the limitation that; "The method of claim 1 wherein said step 
of negotiating a machine interpretable service specification between all parties further comprises 
the step of providing a contract for governing the negotiated service specification.". The 
teachings of Schneier et al are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 
28, whereas the setup of wagers, game selection, players selection/authentication, payment 
authorization, etc., on a per player per se, and multiple player embodiments (col. 12,lines 35-col 
17,line 27), particularly, clearly teaches of 'providing a contract for governing the negotiated 
service specification' as to the setup prior to playing online games insofar as the contract at the 
very least involves the financial/payment aspects of the player (i.e., his credit card 
information).); 

Further, as per claim 21 additionally reciting the limitation that; "The apparatus of claim 
17 wherein said at least one host computer is further operative to provide a contract for 
governing the negotiated service specification.". The teachings of Schneier et al are directed 
towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game 
selection, players selection/authentication, payment authorization, etc., on a per player per se, 
and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 
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'providing a contract for governing the negotiated service specification' as to the setup prior to 
playing online games insofar as the contract at the very least involves the financial/payment 
aspects of the player (i.e., his credit card information).). 



14. Claim 10 additionally recites the limitation that; "The method of claim 1 wherein said 
secure processing steps further comprises the step of notifying said requestor that said service 
request was processed.". The teachings of Schneier et al are directed towards such limitations 
(i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game selection, players 
selection/authentication, payment authorization, etc., on a per player per se, and multiple player 
embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of c step of notifying 
said requestor that said service request was processed 7 as to the setup prior to playing online 
games insofar as the contract at the very least involves the financial/payment aspects of the 
player (i.e., his credit card information), and confirming a credit card is sufficiently funded ); 

Further, as per claim 29 additionally reciting the limitation that; "The apparatus of claim 
17 wherein said at least one host computer operative to provide notifications is further operative 
to notify said requestor that said service request was processed ". The teachings of Schneier et al 
are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of 
wagers, game selection, players selection/authentication, payment authorization, etc., on a per 
player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches of ' step of notifying said requestor that said service request was processed' as to 
the setup prior to playing online games insofar as the contract at the very least involves the 
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financial/payment aspects of the player (i.e., his credit card information), and confirming a credit 
card is sufficiently funded.). 



15. Claim 1 1 additionally recites the limitation that; "The method of claim 1 wherein said 
step of enforcing said service specification further comprises the step of uploading at least one 
database from at least one party of said cooperating parries, information contained therein from 
said at least one database is stored in said host system.". The teachings of Schneier et al are 
directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of 
wagers, game selection, players selection/authentication, payment authorization, etc., on a per 
player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches, insofar as the game rule enforcement associated with specific game playing, as 
broadly interpreted by the examiner would clearly encompass 'uploading at least one database . . . 
is stored in said host system' insofar as the user information at the client and server databases 
associated with the game communicate intermediate results/messages (i.e., handshaking, 
authentication results/requests for further information, etc.) as part of the 
setup/authorization/authentication process ); 

Further, as per claim 27 additionally reciting the limitation that; "The apparatus of claim 
17 wherein said at least one host computer is further operative to upload at least one database 
from at least one party of said cooperating parties, information contained therein from said at 
least one database is adapted to be stored in said host computer.". The teachings of Schneier et al 
are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of 
wagers, game selection, players selection/authentication, payment authorization, etc., on a per 
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player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches, insofar as the game rule enforcement associated with specific game playing, as 
broadly interpreted by the examiner would clearly encompass 'uploading at least one database . . . 
is stored in said host system' insofar as the user information at the client and server databases 
associated with the game communicate intermediate results/messages (i.e., handshaking, 
authentication results/requests for further information, etc.) as part of the 
setup/authorization/authentication process.). 

16. Claim 12 additionally recites the limitation that; "The method of claim 4 wherein said 
step of negotiating multiple machine interpretable service specifications between any 
cooperating parties further comprises the step of providing a contract for governing each 
negotiated service specification ". The teachings of Schneier et al are directed towards such 
limitations (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game selection, 
players selection/authentication, payment authorization, etc., on a per player per se, and multiple 
player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 'providing a 
contract for governing each negotiated service specification' as to the setup prior to playing 
online games insofar as the contract at the very least involves the financial/payment aspects of 
the player (i.e., his credit card information).). 

17. Claim 13 additionally recites the limitation that; "The method of claim 1 wherein said 
step of providing conditional notifications further comprises the step of providing a notification 
that is adapted to contain information about said individual.". The teachings of Schneier et al are 
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directed towards such limitations (i.e., col. 5,lines 38-col. 6,line 38, whereas the players 
selection/authentication on a per player per se, and multiple player embodiments (col. 12,lines 
35-col 17,line 27), particularly, clearly teaches of the messaging protocols, as broadly interpreted 
by the examiner and would clearly encompass 'providing a notification that is adapted to contain 
information about said individual' insofar as the user information at the client and server 
databases associated with the game communicate intermediate results/messages (i.e., 
handshaking, authentication results/requests for further information, etc.) as part of the 
setup/authorization/authentication process, and said messages clearly (i.e., again, in the case of 
handshaking, authentication results/requests for further information, etc.) encompass said 
affirmative verification of financial/authentication of user/user specified gaming information 
messages.); 

Further, as per claim 30 additionally reciting the limitation that; "The apparatus of claim 
27 wherein said at least one host computer operative to provide notifications is further operative 
to provide conditional notifications that is adapted to contain information about an individual.". 
The teachings of Schneier et al are directed towards such limitations (i.e., col 5,lines 38-col. 
6,line 38, whereas the players selection/authentication on a per player per se, and multiple player 
embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of the messaging 
protocols, as broadly interpreted by the examiner and would clearly encompass 'providing a 
notification that is adapted to contain information about said individual' insofar as the user 
information at the client and server databases associated with the game communicate 
intermediate results/messages (i.e., handshaking, authentication results/requests for further 
information, etc.) as part of the setup/authorization/authentication process, and said messages 
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clearly (i.e., again, in the case of handshaking, authentication results/requests for further 
information, etc.) encompass said affirmative verification of financial/authentication of user/user 
specified gaming information messages.). 

18. Claim 14 additionally recites the limitation that; "The method of claim 13, wherein said 
step of providing a notification that is adapted to contain information about said individual 
further comprises the step of providing said notification to at least one party of said cooperating 
parties, said at least one party of said cooperating parties is a party other than said requestor ". 
The teachings of Schneier et al are directed towards such limitations (i.e., col. 5,lines 38-col. 
6,line 38, whereas the players selection/authentication on a per player per se, and multiple player 
embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of the messaging 
protocols, as broadly interpreted by the examiner and would clearly encompass 'providing said 
notification . . . other than said requestor 5 insofar as the user information at the client and server 
databases associated with the game communicate intermediate results/messages (i.e., 
handshaking, authentication results/requests for further information, etc.) as part of the 
setup/authorization/authentication process, and said messages clearly (i.e., again, in the case of 
handshaking, authentication results/requests for further information, etc.) encompass said 
affirmative verification of financial/authentication of user/user specified gaming information 
messages, and further, the multiple players client network nodes clearly communicate 
interactively during game setup and actual game playing.); 

Further, as per claim 3 1 additionally reciting the limitation that; "The apparatus of claim 
18 wherein said at least one host computer is further operative to provide said conditional 
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notifications to another party of said cooperating parties, said another party of said cooperating 
parties is a party other than said requestor". The teachings of Schneier et al are directed towards 
such limitations (i.e., col. 5,lines 38-col. 6,line 38, whereas the players selection/authentication 
on a per player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), 
particularly, clearly teaches of the messaging protocols, as broadly interpreted by the examiner 
and would clearly encompass 'providing said notification . . . other than said requestor' insofar as 
the user information at the client and server databases associated with the game communicate 
intermediate results/messages (i.e., handshaking, authentication results/requests for further 
information, etc.) as part of the setup/authorization/authentication process, and said messages 
clearly (i.e., again, in the case of handshaking, authentication results/requests for further 
information, etc.) encompass said affirmative verification of financial/authentication of user/user 
specified gaming information messages, and further, the multiple players client network nodes 
clearly communicate interactively during game setup and actual game playing.). 

19. Claim 15 additionally recites the limitation that; "The method of claim 14, wherein said 
step of providing a notification to at least one party of said cooperating parties that is adapted to 
contain information about said individual further comprises the step of providing notification to 
said at least one party of said cooperating parties that is a party other than a provider of said 
stored data.". The teachings of Schneier et al are directed towards such limitations (i.e., col. 
5,lines 38-col. 6,line 38, whereas the players selection/authentication on a per player per se, and 
multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of the 
messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
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'providing notification . . . other than a provider of said stored data' insofar as the user 
information at the client and server databases associated with the game communicate 
intermediate results/messages (i.e., handshaking, authentication results/requests for further 
information, etc.) as part of the setup/authorization/authentication process, and said messages 
clearly (i.e., again, in the case of handshaking, authentication results/requests for further 
information, etc.) encompass said affirmative verification of financial/authentication of user/user 
specified gaming information messages, and further, the multiple players client network nodes 
clearly communicate interactively during game setup and actual game playing ); 

Further, as per claim 32 additionally reciting the limitation that; "The method of claim 
31, wherein said at least one host computer operative to provide said conditional notifications to 
said another party of said cooperating parties is further operative to provide said conditional 
notifications to a party other than a provider of said stored data.". The teachings of Schneier et al 
are directed towards such limitations (i.e., col. 5,lines 38-col. 6,line 38, whereas the players 
selection/authentication on a per player per se, and multiple player embodiments (col. 12,lines 
35-col 17,line 27), particularly, clearly teaches of the messaging protocols, as broadly interpreted 
by the examiner and would clearly encompass 'providing notification ... other than a provider of 
said stored data 5 insofar as the user information at the client and server databases associated with 
the game communicate intermediate results/messages (i.e., handshaking, authentication 
results/requests for further information, etc.) as part of the setup/authorization/authentication 
process, and said messages clearly (i.e., again, in the case of handshaking, authentication 
results/requests for further information, etc.) encompass said affirmative verification of 
financial/authentication of user/user specified gaming information messages, and further, the 
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multiple players client network nodes clearly communicate interactively during game setup and 
actual game playing.). 



20. Claim 16 additionally recites the limitation that; "The method of claim 1 wherein said 
step of providing conditional notifications further comprises the step of providing a notification 
to at least one party of said cooperating parties that is adapted to contain no information about 
said individual.". The teachings of Schneier et al are directed towards such limitations (i.e., col. 
5,lines 38-col. 6, line 38, whereas the players selection/authentication on a per player per se, and 
multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of the 
messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
'providing a notification ... to contain no information about said individual' insofar as the user 
information at the client and server databases associated with the game communicate 
intermediate results/messages (i.e., handshaking, authentication results/requests for further 
information, etc.) as part of the setup/authorization/authentication process, and said messages 
clearly (i.e., again, in the case of handshaking, authentication results/requests for further 
information, etc.) encompass said affirmative verification of financial/authentication of user/user 
specified gaming information messages that in acting as a simple verification/authentication of 
user without explicit user identification (i.e., acknowledgement of message via IP address and 
not user of network node at said IP address).). 

21. Claim 18 additionally recites the limitation that; "The apparatus of claim 17, wherein 
said at least one host computer is further operative to define said service specification to: identify 
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said cooperating parties (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of players 
selection/authentication, on a per player per se, and multiple player embodiments (col. 12,lines 
35-col 17,line 27), particularly, clearly teaches of 'identify cooperating parties'); identify said 
requestor and the format of said service request, said request is adapted to contain information 
about an individual (i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of players 
selection/authentication, on a per player per se, and multiple player embodiments (col. 12,lines 
35-col 17,line 27), particularly, clearly teaches of 'requestor and format of a service request' 
insofar as the communications protocols of the game initiator at least is concerned (i.e., figure 4 
and associated description).); conduct conditional processing steps required for said service 
request, said conditional processing steps is adapted to use stored data about said individual (i.e., 
col. 1, lines 55-col. 17,line 28, whereas the setup of players selection/authentication, on a per 
player per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, 
clearly teaches of 'conditional processing steps is adapted to use stored data about said 
individual'.); and provide conditional notifications, said conditional notifications is adapted to 
include additional information about the individual described in the request (i.e., col. 1, lines 55- 
col. 17,line 28, whereas the setup of players selection/authentication, on a per player per se, and 
multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 
'additional information about the individual described in the request' insofar as the requestor 
clearly must have submitted user information in the game registration process as any of the other 
player are similarly required to do so.).". The teachings of Schneier et al are directed towards 
such limitations (i.e., col. 1, lines 55-col. 17,line 28). 
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22. Claim 19 additionally recites the limitation that; "The apparatus of claim 17 wherein said 
at least one host computer is further operative to execute said secure processing to: determine the 
service specification that governs said service request; validate said requestor and the content of 
the service request against an expected requestor and expected contents as defined in the service 
specification; and execute conditional processing as defined in the service specification.". The 
teachings of Schneier et al are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 
28, whereas the cryptographic processors, on a per player user client terminal and server side 
host, clearly teaches of 'secure computation environment . . . ' insofar as the authentication and 
actual game playing cryptographic functions serviced via the cryptographic processor secure 
computing environment.). 

23. Claim 20 additionally recites the limitation that; "The apparatus of claim 17 wherein said 
at least one host computer is further operative to provide said notifications as conditional 
notifications that is adapted to include additional information about an individual described in 
the request.". The teachings of Schneier et al are directed towards such limitations (i.e., col. 1, 
lines 55-col. 17,line 28, whereas the setup of players selection/authentication, on a per player per 
se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly 
teaches of 'additional information about the individual described in the request' insofar as the 
requestor clearly must have submitted user information in the game registration process as any of 
the other player are similarly required to do so.). 
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24. As per claim 33; "An identification apparatus for matching individuals, the apparatus 
comprising: at least one host computer adapted to have at least one secure co-processor operating 
in a secure computation environment, said at least one host computer operative to: negotiate a 
machine interpretable contract between all parties, which would cooperate with a particular 
application running on said host computer; upload said contract into said secure computation 
environment; enforce said contract with regards to all cooperating parties; receive a service 
request from a requestor, execute secure processing of said service request; and provide 
notifications as defined in the contract [This claim is the system as applied to the identification 
aspects of the claim for the method claims 1 and 9 above, and is rejected for the same reasons 
provided for the claim 1 and 9 rejections]."; 

Further, as per claim 37; "An identification method [This claim is the method claim for 
the system claim 33 above, and is rejected for the same reasons provided for the claim 33 
rejection] for matching individuals, the method comprising the steps of: providing at least one 
host computer adapted to have at least one secure co-processor operating in a secure computation 
environment; operating said at least one host computer to negotiate a machine interpretable 
contract between all parties, which would cooperate with a particular application running on said 
host computer; uploading said contract into said secure computation environment; enforcing said 
contract with regards to all cooperating parties; receiving a service request from a requestor; 
executing secure processing of said service request; and providing notifications as defined in the 
contract."; 

Further, as per claim 39; "A program storage device readable by a machine, tangibly 
embodying a program of instructions executable by the machine to perform methods steps [This 
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claim is the embodied software claim for the method claim 37 above, whereas this claim ' 
involves 'negotiate ... service specification between all parties' versus the claim 37 'negotiate ... 
contract between all parties'. The phrases 'negotiate ... contract between all parties', and 
'negotiate . . . service specification between all parties' as broadly interpreted by the examiner, 
are equivalent insofar as the negotiation of the service specification is an instance of the contract 
(i.e., the contract is the 'framework or protocol' upon which the service specification is based, 
and the protocol of user initiation/player parameters as entered and stored in the server/clients 
clearly establishes equivalency, and is rejected for the same reasons provided for the claim 37 
rejection] for managing a matching identification service, the method comprising the steps of: 
providing at least one host computer adapted to have at least one secure co-processor operating 
in a secure computation environment; operating said at least one host computer to negotiate a 
machine interpretable service specification between all parties, which would cooperate with a 
particular application running on said host computer; uploading said service specification into 
said secure computation environment; enforcing said service specification with regards to all 
cooperating parties; receiving a service request from a requestor; executing secure processing of 
said service request; and providing notifications as defined in the service specification "; 

Further, as per claim 40; "An article of manufacture [This claim is the embodied software 
claim for the method claim 37 above, and is rejected for the same reasons provided for the claim 
37 rejection] for use in matching individuals, comprising a machine readable medium tangibly 
embodying a program of instructions executable by a machine for implementing a method, the 
method comprising steps of: providing at least one host computer adapted to have at least one 
secure co-processor operating in a secure computation environment; operating said at least one 
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host computer to negotiate a machine interpretable contract between all parties, which would 
cooperate with a particular application running on said host computer; uploading said contract 
into said secure computation environment; enforcing said contract with regards to all cooperating 
parties; receiving a service request from a requestor; executing secure processing of said service 
request; and providing notifications as defined in the contract."; 

Further, as per claim 41; "A program storage device readable by a machine, tangibly 
embodying a program of instructions executable by the machine to perform methods steps [This 
claim is the embodied software claim for the method claim 37 above, and is rejected for the same 
reasons provided for the claim 37 rejection] for managing a matching identification service, the 
method comprising the steps of: providing at least one host computer adapted to have at least one 
secure co-processor operating in a secure computation environment; operating said at least one 
host computer to negotiate a machine interpretable contract between all parties, which would 
cooperate with a particular application running on said host computer; uploading said contract 
into said secure computation environment; enforcing said contract with regards to all cooperating 
parties; receiving a service request from a requestor; executing secure processing of said service 
request; and providing notifications as defined in the contract "; 

Further, as per claim 42; "A computer-based method [This claim is the more specific 
version of claim 37 above, such that the server/client and 'other node' is involved. The electronic 
gaming network consisting of a server (i.e., game server service provider application common to 
all players), and clients (i.e., the terminal players) interactively linked by the inherent nature of 
said network games, as broadly interpreted by the examiner, are equivalent insofar as the clients 
clearly being interactive pass information between themselves. Therefore, claim 42 is rejected 
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for the same reasons provided for the claim 37 rejection.] for a multiparty electronic service, the 
method comprising steps of: implementing on a computer system at least one contract for 
governing a service between a service provider, a client and at least one other party; receiving at 
said service provider a first request from a client; sending from said service provider a data 
request to one of at least one other party; receiving, at said service provider from said one of at 
least one other party, a data response in a secure computation environment; determining, in 
accordance with said contract, whether a match exists between said first request and said data 
response; if a match results from said determining step, providing a notification of said match to 
said at least one other party."; 



25. Claim 43 additionally recites the limitation that; "The method of claim 42 further 
comprises the step of providing said notification even if there is no match as determined in said 
determining step ". The teachings of Schneier et al are directed towards such limitations (i.e., col. 
5, lines 38-col. 6,line 38, whereas the players selection/authentication on a per player per se, and 
multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of the 
messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
'providing said notification ... no match . . . determining step' insofar as the user information at 
the client and server databases associated with the game communicate intermediate 
results/messages (i.e., handshaking, authentication results/requests for further information, etc.) 
as part of the setup/authorization/authentication process, and said messages clearly (i.e., again, in 
the case of handshaking, authentication results/requests for further information, etc.) encompass 
said affirmative verification of financial/authentication of user/user specified gaming information 
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messages that in acting as a simple verification/authentication of user without explicit user 
identification (i.e., acknowledgement of message via IP address and not user of network node at 
said IP address).). 

26. Claim 44 additionally recites the limitation that; "The method of claim 43, wherein said 
step of providing said notification comprises the step of providing a dummy message to said at 
least one other party.". The teachings of Schneier et al are directed towards such limitations (i.e., 
col. 5,lines 38-col. 6,line 38, whereas the players selection/authentication on a per player per se, 
and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 
the messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
'providing said notification comprises the step of providing a dummy message' insofar as the 
user information at the client and server databases associated with the game communicate 
intermediate results/messages (i.e., handshaking, authentication results/requests for further 
information, etc.) as part of the setup/authorization/authentication process, and said messages 
clearly (i.e., again, in the case of handshaking, authentication results/requests for further 
information, etc.) encompass said empty messages.). 

27. Claim 45 additionally recites the limitation that; "The method of claim 42 further 
comprises the step of notifying said client that said first request was processed.". The teachings 
of Schneier et al are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, 
whereas the setup of wagers, game selection, players selection/authentication, payment 
authorization, etc., on a per player per se, and multiple player embodiments (col. 12,lines 35-col 
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17,line 27), particularly, clearly teaches of 'step of notifying said requestor that said service 
request was processed' as to the setup prior to playing online games insofar as the contract at the 
very least involves the financial/payment aspects of the player (i.e., his credit card information), 
and confirming a credit card is sufficiently funded.). 

28. Claim 46 additionally recites the limitation that; "The method of claim 42 wherein the 
implementing the at least one contract step comprises the step of assigning a contract ID for any 
contract that governs a service between the service provider, the client and the at least one other 
party.". The teachings of Schneier et al are directed towards such limitations (i.e., col. 1, lines 
55-col. 17,line 28, whereas the setup of wagers, game selection, players selection/authentication, 
payment authorization, etc., on a per player per se, and multiple player embodiments (col. 
12,lines 35-col 17,line 27), particularly, clearly teaches of ' ... step of assigning a contract ID 
for any contract . . . between the service provider, the client and the at least one other party' as to 
the setup prior to playing online games insofar as the contract at the very least involves the 
financial/payment aspects of the player (i.e., his credit card information), which has a 'specific 
game played here and now 5 identification aspect (i.e., the IP address of the clients using said 
contract at the any given game).). 

29. Claim 47 additionally recites the limitation that; "The method of claim 42 further 
comprises the step of executing the previous steps in a contract engine within the secure 
computation environment.". The teachings of Schneier et al are directed towards such limitations 
(i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game selection, players 
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selection/authentication, payment authorization, etc., on a per player per se, and multiple player 
embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of ' ... step of 
executing the previous steps in a contract engine within' insofar as the gaming system 
architecture is clearly modular (i.e., client/server based at the hardware and software levels of 
abstraction), of which the "engine" modularity data structure, as broadly interpreted by the 
examiner, is so encompassed.). 

30. Claim 48 additionally recites the limitation that; "The method of claim 47 further 
comprises the step of providing a plurality of contract engines coupled to a communication 
network.". The teachings of Schneier et al are directed towards such limitations (i.e., col. 1, lines 
55-col. 17,line 28, whereas the setup of wagers, game selection, players selection/authentication, 
payment authorization, etc., on a per player per se, and multiple player embodiments (col. 
12,lines 35-col 17,line 27), particularly, clearly teaches of ... providing a plurality of contract 
engines coupled to a communication network' insofar as the contract is clearly executed on the 
individual client terminals, as broadly interpreted by the examiner.). 

3 1 . Claim 49 additionally recites the limitation that; "The method of claim 42 wherein the 
determining step comprises the step of performing the determination in a crypto-coprocessor.". 
The teachings of Schneier et al are directed towards such limitations (i.e., col. 1, lines 55-col. 
17,line 28, whereas the cryptographic processors, on a per player user client terminal and server 
side host, clearly teaches of 'determination in a crypto-coprocessor' insofar as the authentication 
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and actual game playing cryptographic functions serviced via the cryptographic processor secure 
computing environment.). 



32. As per claim 50; "A computer-based method [This claim is the more general version of 
claim 37 above, such that the server/client and 'other node' is involved. The electronic gaming 
network consisting of a server (i.e., game server service provider application common to all 
players), and clients (i.e., the terminal players) interactively linked by the inherent nature of said 
network games, as broadly interpreted by the examiner, are equivalent insofar as the clients 
clearly being interactive pass information between themselves. Therefore, claim 42 is rejected 
for the same reasons provided for the claim 37 rejection.] for a multiparty electronic service, the 
method comprising steps of: implementing on a computer system at least one contract for 
governing a service between a service provider, a client and at least one other party; determining, 
in accordance with said contract, whether a match exists between a first request from said client 
and a data response from one of at least one other party; if a match results from said determining 
step, providing a notification of said match to said at least one other party."; 

Further, as per claim 59; "Apparatus [This claim is the system claim for the method claim 
50 above, and is rejected for the same reasons provided for the claim 50 rejection] for a 
multiparty electronic service, the apparatus comprising: at least one host computer operative to: 
maintain and enforce at least one contract for governing a service between a service provider, a 
client and at least one other party; and to determine, in accordance with said at least one contract, 
whether a match exists between a first request from said client and a data response from one of at 
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least one other party; said at least one host computer is further operative to provide a notification 
to said at least one other party if a match results from said determination." 



33. Claim 51 additionally recites the limitation that; "The method of claim 50 further 
comprises the step of providing said notification even if there is no match as determined in said 
determining step ". The teachings of Schneier et al are directed towards such limitations (i.e., col. 
5,lines 38-col. 6,line 38, whereas the players selection/authentication on a per player per se, and 
multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of the 
messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
'providing said notification ... no match . . . determining step' insofar as the user information at 
the client and server databases associated with the game communicate intermediate 
results/messages (i.e., handshaking, authentication results/requests for further information, etc.) 
as part of the setup/authorization/authentication process, and said messages clearly (i.e., again, in 
the case of handshaking, authentication results/requests for further information, etc.) encompass 
said affirmative verification of financial/authentication of user/user specified gaming information 
messages that in acting as a simple verification/authentication of user without explicit user 
identification (i.e., acknowledgement of message via IP address and not user of network node at 
said BP address).); 

Further, as per claim 60 additionally reciting the limitation that; "The apparatus [This 
claim is the system claim for the method claim 5 1 above, and is rejected for the same reasons 
provided for the claim 51 rejection] of claim 59, wherein said at least one host computer is 
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further operative to provide said notification to said at least one other party if no match results 
from said determination ". 



34. Claim 52 additionally recites the limitation that; "The method of claim 51, wherein said 
step of providing said notification comprises the step of providing a dummy message to said at 
least one other party.". The teachings of Schneier et al are directed towards such limitations (i.e., 
col. 5,lines 38-col. 6,line 38, whereas the players selection/authentication on a per player per se, 
and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 
the messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
'providing said notification comprises the step of providing a dummy message 5 insofar as the 
user information at the client and server databases associated with the game communicate 
intermediate results/messages (i.e., handshaking, authentication results/requests for further 
information, etc.) as part of the setup/authorization/authentication process, and said messages 
clearly (i.e., again, in the case of handshaking, authentication results/requests for further 
information, etc.) encompass said empty messages.); 

Further, as per claim 61 additionally reciting the limitation that; "The apparatus [This 
claim is the system claim for the method claim 52 above, and is rejected for the same reasons 
provided for the claim 52 rejection] of claim 60, wherein said at least one host computer is 
further operative to provide a dummy message to said at least one other party.". 

35. Claim 53 additionally recites the limitation that; "The method of claim 50 further 
comprises the step of notifying said client that said first request was processed.". The teachings 



Application/Control Number: 10/065,802 Page 36 

Art Unit: 2136 

of Schneier et al are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, 
whereas the setup of wagers, game selection, players selection/authentication, payment 
authorization, etc., on a per player per se, and multiple player embodiments (col. 12,lines 35-col 
17,line 27), particularly, clearly teaches of 'step of notifying said requestor that said service 
request was processed' as to the setup prior to playing online games insofar as the contract at the 
very least involves the financial/payment aspects of the player (i.e., his credit card information), 
and confirming a credit card is sufficiently funded.); 

Further, as per claim 62 additionally reciting the limitation that; "The apparatus [This 
claim is the system claim for the method claim 53 above, and is rejected for the same reasons 
provided for the claim 53 rejection] of claim 59, wherein said at least one host computer is 
further operative to provide a notification to said client that said first request was processed/'. 

36. Claim 63 additionally recites the limitation that; "The apparatus [This claim is the system 
claim for the database and communications aspects of method claim 1 1 above, and is rejected for 
the same reasons provided for the claim 1 1 rejection] of claim 59, wherein said at least one host 
computer comprises: a secure computation environment for processing sensitive data; a network 
handler for sending and receiving messages to and from said secure computation environment 
and a network; and a storage handler to process database requests that come from inside said 
secure computation environment and retrieves information from a secured database containing 
said contracts and private information data.". 
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37. Claim 54 additionally recites the limitation that; "The method of claim 50 wherein the 
implementing the at least one contract step comprises the step of assigning a contract ID for any 
contract that governs a service between the service provider, the client and the at least one other 
party .". The teachings of Schneier et al are directed towards such limitations (i.e., col. 1, lines 
55-col. 17,line 28, whereas the setup of wagers, game selection, players selection/authentication, 
payment authorization, etc., on a per player per se, and multiple player embodiments (col. 
12,lines 35-col 17,line 27), particularly, clearly teaches of ... step of assigning a contract ID 
for any contract . . . between the service provider, the client and the at least one other party' as to 
the setup prior to playing online games insofar as the contract at the very least involves the 
financial/payment aspects of the player (i.e., his credit card information), which has a 'specific 
game played here and now' identification aspect (i.e., the IP address of the clients using said 
contract at the any given game).); 

Further, as per claim 64 additionally reciting the limitation that; "The apparatus [This 
claim is the system claim for the method claim 54 above, and is rejected for the same reasons 
provided for the claim 54 rejection] of claim 59, wherein said at least one host computer is 
further operative to provide a contract ID for any contract that governs a service between the 
service provider, the client and the at least one other party.". 

38. As per claim 55; "A computer-based method [This claim is the combination of claims 50 
and 54, and is rejected for the same reasons provided for the claim 50,54 rejections ] for 
managing a matching identification service, the method comprising the steps of: implementing 
on a computer system at least one contract having a contract ID for governing said matching 
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identification service between a service provider, a client and at least one other party 
determining, in accordance with said contract ID, whether a match exists between a first request 
from said client and a data response from one of at least one other party; if a match results from 
said determining step, providing a notification of said match to said at least one other party."; 

Further, as per claim 65; "Apparatus [This claim is the system claim for the method claim 
55 above, and is rejected for the same reasons provided for the claim 55 rejection] for a matching 
identification service, the apparatus comprising: at least one host computer operative to: maintain 
and enforce at least one contract having a contract ID for governing a service between a service 
provider, a client and at least one other party; and to determine, in accordance with said at least 
one contract, whether a match exists between a first request from said client and a data response 
from one of at least one other patty; said at least one host computer is further operative to 
provide a notification to said at least one other party if a match results from said determination 

39. Claim 66 additionally recites the limitation that; "The apparatus [This claim is the system 
claim for the database and communications aspects of method claim 1 1 above, and is rejected for 
the same reasons provided for the claim 1 1 rejection] of claim 65, wherein said at least one host 
computer comprises: a secure computation environment for processing sensitive data; a network 
handler for sending and receiving messages to and from said secure computation environment 
and a network; and a storage handler to process database requests that come from inside said 
secure computation environment and retrieves information from a secured database containing 
said contracts and private information data.". 
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40. Claim 67 additionally recites the limitation that; "The apparatus of claim 66, wherein 
said secure computation environment comprises a contract engine operative to: handle said first 
request, conduct a matching task, and provide a respond serving as said notification ". The 
teachings of Schneier et al are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 
28, whereas the setup of wagers, game selection, players selection/authentication, payment 
authorization, etc., on a per player per se, and multiple player embodiments (col. 12,lines 35-col 
17,line 27), particularly, clearly teaches of ... computation environment comprises a contract 
engine operative to: handle . . . ' insofar as the gaming system architecture is clearly modular 
(i.e., client/server based at the hardware and software levels of abstraction), of which the 
"engine" modularity data structure, as broadly interpreted by the examiner, is so encompassed, 
and clearly as described above, comprises a crypto-processor, etc., (i.e., the secure computing 
environment).). 

41 . Claim 68 additionally recites the limitation that; "The apparatus of claim 65, wherein 
said at least one host computer is further operative to provide said notification to said at least one 
other party if no match results from said determination". The teachings of Schneier et al are 
directed towards such limitations (i.e., col. 5,lines 38-col. 6,line 38, whereas the players 
selection/authentication on a per player per se, and multiple player embodiments (col. 12,lines 
35-col 17,line 27), particularly, clearly teaches of the messaging protocols, as broadly interpreted 
by the examiner and would clearly encompass 'providing said notification ... no match . . . 
determining step' insofar as the user information at the client and server databases associated 
with the game communicate intermediate results/messages (i.e., handshaking, authentication 
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results/requests for further information, etc.) as part of the setup/authorization/authentication 
process, and said messages clearly (i.e., again, in the case of handshaking, authentication 
results/requests for further information, etc.) encompass said affirmative verification of 
financial/authentication of user/user specified gaming information messages that in acting as a 
simple verification/authentication of user without explicit user identification (i.e., 
acknowledgement of message via IP address and not user of network node at said IP address).). 

42. Claim 56 additionally recites the limitation that; "The method of claim 55 further 
comprises the step of providing said notification even if there is no match as determined in said 
determining step.". The teachings of Schneier et al are directed towards such limitations (i.e., col. 
5,lines 38-col. 6,line 38, whereas the players selection/authentication on a per player per se, and 
multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of the 
messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
'providing said notification ... no match . . . determining step' insofar as the user information at 
the client and server databases associated with the game communicate intermediate 
results/messages (i.e., handshaking, authentication results/requests for further information, etc.) 
as part of the setup/authorization/authentication process, and said messages clearly (i.e., again, in 
the case of handshaking, authentication results/requests for further information, etc.) encompass 
said affirmative verification of financial/authentication of user/user specified gaming information 
messages that in acting as a simple verification/authentication of user without explicit user 
identification (i.e., acknowledgement of message via IP address and not user of network node at 
said IP address).). 



Application/Control Number: 10/065,802 
Art Unit: 2136 



Page 41 



43. Claim 57 additionally recites the limitation that; "The method of claim 56, wherein said 
step of providing said notification comprises the step of providing a dummy message to said at 
least one other party ". The teachings of Schneier et al are directed towards such limitations (i.e., 
col. 5,lines 38-col. 6,line 38, whereas the players selection/authentication on a per player per se, 
and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 
the messaging protocols, as broadly interpreted by the examiner and would clearly encompass 
'providing said notification comprises the step of providing a dummy message' insofar as the 
user information at the client and server databases associated with the game communicate 
intermediate results/messages (i.e., handshaking, authentication results/requests for further 
information, etc.) as part of the setup/authorizat ion/authentication process, and said messages 
clearly (i.e., again, in the case of handshaking, authentication results/requests for further 
information, etc.) encompass said empty messages.). 

44. Claim 58 additionally recites the limitation that; "The method of claim 56 further 
comprises the step of notifying said client that said first request was processed.". The teachings 
of Schneier et al are directed towards such limitations (i.e., col. 1, lines 55-col. 17,line 28, 
whereas the setup of wagers, game selection, players selection/authentication, payment 
authorization, etc., on a per player per se, and multiple player embodiments (col. 12,lines 35-col 
17,line 27), particularly, clearly teaches of 'step of notifying said requestor that said service 
request was processed' as to the setup prior to playing online games insofar as the contract at the 
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very least involves the financial/payment aspects of the player (i.e., his credit card information), 
and confirming a credit card is sufficiently funded.). 

45. As per claim 36; "A multiparty electronic service method [i.e., Abstract, whereas the 
playing of electronic games over a network by one or more players corresponds to the 
'multiparty electronic service'] comprising the steps of: providing at least one host computer 
adapted to have at least one secure co-processor operating in a secure computation environment 
[i.e., col. 1, lines 55-col. 17,line 28, whereas the cryptographic processors, on a per player user 
client terminal and server side host, clearly teaches of 'secure computation environment 5 .]; 
operating said at least one host computer to negotiate a machine interpretable service 
specification between all parties, which would cooperate with a particular application running on 
said host computer [i.e., col. 1, lines 55-col. 17,line 28, whereas the setup of wagers, game 
selection, players selection/authentication, payment authorization, etc., on a per player per se, 
and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 
'service specification between all parties' as to the setup prior to playing online 
games/establishing associated random number information associated with said playing of 
games.]; uploading said service specification into said secure computation environment [i.e., col. 
1, lines 55-col. 17,line 28, whereas the setup of players selection/authentication, on a per player 
per se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly 
teaches of 'uploading said service specification' insofar as the clients and servers clearly have 
the same rules and all associated information required to play.]; enforcing said service 
specification with regards to all cooperating parties [i.e., col. 1, lines 55-col. 17,line 28, whereas 
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the setup of players selection/authentication, on a per player per se, and multiple player 
embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly teaches of 'enforcing said 
service specification with regards to all cooperating parties' insofar as the clients and servers 
clearly have the same rules and all associated information required to play, and as such use said 
information during the actual game playing.]; receiving a service request from a requestor [i.e., 
col. 1, lines 55-col. 17,line 28, whereas the subsequent to the setup of players 
select ion/authenticat ion, on a per player per se, and multiple player embodiments (col. 12,lines 
35-col 17,line 27), particularly, clearly teaches of 'receiving a service request from said 
requestor' insofar as the clients and servers clearly have the same rules and all associated 
information required to play, and as such use said information during the actual game playing.]; 
executing secure processing of said service request [i.e., col. 1, lines 55-col. 17,line 28, whereas 
the cryptographic processors, on a per player user client terminal and server side host, clearly 
teaches of 'secure computation environment' insofar as the authentication and actual game 
playing cryptographic functions serviced via the cryptographic processor secure computing 
environment.]; and providing notifications as defined in the service specification [i.e., col. 1, 
lines 55-col. 17,line 28, whereas the setup of players selection/authentication, on a per player per 
se, and multiple player embodiments (col. 12,lines 35-col 17,line 27), particularly, clearly 
teaches of 'additional information about the individual described in the request' insofar as the 
requestor clearly must have submitted user information in the game registration process as any of 
the other player are similarly required to do so.]."; 

Further, as per claim 38; "An article of manufacture [This claim is the embodied software 
claim for the method claim 36 above, and is rejected for the same reasons provided for the claim 
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36 rejection] for use in a multiparty electronic service, comprising a machine readable medium 
tangibly embodying a program of instructions executable by a machine for implementing a 
method, the method comprising steps of: providing at least one host computer adapted to have at 
least one secure co-processor operating in a secure computation environment; operating said at 
least one host computer to negotiate a machine interpretable service specification between ail 
parties, which would cooperate with a particular application running on said host computer; 
uploading said service specification into said secure computation environment; enforcing said 
service specification with regards to all cooperating parties; receiving a service request from a 
requestor; executing secure processing of said service request; and providing notifications as 
defined in the service specification.". 



46. Any inquiry concerning this communication or earlier communications from examiner 
should be directed to Ronald Baum, whose telephone number is (571) 272-3681, and whose 
unofficial Fax number is (571) 273-3681. The examiner can normally be reached Monday 
through Friday from 8:00 AM to 5:30 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ayaz Sheikh, can be reached at (571) 272-3795. The Fax number for the organization 
where this application is assigned is 703-872-9306. /~\ /? fj 
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